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■fr Sales of FileMaker Plus continue to grow. To some extent, File¬ 
Maker has been a word-of mouth product. One characteristic of such 
products is that as the cumulative numbers of happy users grows, 
additional sales tend to multiply since there is a bigger pool of mouths 
to do the talking. 

■fr Nashoba’s west-coast office has been busy and is now well- 
staffed, well-organized, full of various Macintoshes and peripherals 
and networks. They even have some furniture now! The support line 
continues to give good service and help for those in need. 

It turns out that many FileMaker owners have not registered their 
ownership. I urge you to do so. Among other things, registration 
means you will receive notification of new versions of FileMaker as 
they become available. Speaking of new versions, the next issue of 
The FileMaker Report will discuss the upcoming new version of File¬ 
Maker. There is much to like in this upgrade; it is clear that Nashoba 
has been listening to their customers and working hard. 

«J> Elk Horn is now undertaking publication of a new newsletter 
called RISC Management. It is devoted to users and builders of RISC 
systems. Written and edited by RISC consultant and expert Andrew 
Allison, RISC Management is the authoritative source of analysis and 
commentary on RISC technologies, products and markets. 

After almost twenty-five years in the background, RISC systems 
(Reduced Instruction Set Computers) have recently become highly 
visible. The trade press is full of references to this ‘new’ technology, 
and even financial and general circulation newspapers are making 
regular reference to RISCs. 

The reason for all this interest is the dawning realization that 
RISCs are going to have a profound impact on the 32-bit computer 
market, from PCs to minisupercomputers. RISC technology has the 
capability to put the performance of high-end minicomputers on the 
desktop. The potential impact and rapid pace of RISC developments 
require that those most affected keep themselves fully informed. 
RISC is proving to be the most important development in the com¬ 
puter industry since the microprocessor. 

Please let us know if you are interested in RISC Management and 
we'll send you more information. The special charter subscription 
rates are good until September 30, 1988. The charter rates are: 


Location 

Continental US plus Alaska & Hawaii, 11 issues 
US Possessions plus Canada & Mexico, 11 issues 
All other worldwide locations, 11 issues 


Regular 

Charter 

$285 

$235 

$300 

$250 

$320 

$270 
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Consulting Resources 


& Additional expertise can prove to be productive with some pro¬ 
jects and in some contexts. Consultants can help design databases 
from scratch, debug existing implementations, provide one-on-one 
instruction and larger training classes. The names listed here are 
potential sources of help when a consultant is needed. They are all 
subscribers but they have not been qualified by the newsletter and 
normal caution should be exercised. Please write if you would like to 
be included on this list or if you have experience with a consultant you 
can recommend. 


S. C. Kim Hunter 

David Lagerson 

Janet Tokerud 

Acropolis Software 

8412 McNulty Avenue 

#1 

24781 Acropolis 

Canoga Park, CA 91306 

322 30th Avenue 

Mission Viejo, CA 92691 

818-352-8711 

San Francisco, CA 94121 

714-250-6280 

Tom Price 

415-751-9330 

John Winson 

Price & Associates 

Michael Degnan 

Frontline Marketing 

PO Box 153 

Suite 6 

PO Box 327 

Peabody, MA 01960 

1447 University Avenue 

Beverly, MA 01915 

617-532-0762 

Berkeley, CA 94702 

617-927-2535 

David Dent 

415-644-2381 

Steve Proehl 

Software Solutions 

Jeff Nathanson 

916 Rodney Drive 

1190 Gravenstein Hwy S 

PO Box 587 

San Leandro, CA 94577 

Sebastopol, CA 95472 

Old Orchard Beach 

415-483-3683 

707-829-5377 

ME 04064 

207-934-7509 

Jonathan Posner 

John Foster 


44 Greenwich Avenue 

Adjuvant Instruments 

Joe Kroeger 

New York, NY 10011 

2834 Johnson Avenue 

Elk Horn Publishing 

212-243-0038 

Alameda, CA 94501 

PO Box 397 

Cupertino, CA 95015 

Mike Singleton 

Jim Schwertman 

408-946-1767 

Professional Design Support 

Mac Solutions 


2315 29th Street 

1168 Willow Glen Way 


San Diego, CA 92104 

San Jose, CA 95125 


619-284-5620 

408-298-4333 



• Consulting 

• Designing 

• Training 
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Preventing Fields from Sliding Up 

FileMaker Plus Is being used by the Association of Women In 
Computing to produce their membership directory. The person doing 
the work has raved about FileMaker Plus and how much simpler it 
has been compared with prior years when they didn’t have FileMaker. 

One problem they faced was printing a directory page with fields 
for name, address, city, state, zip, plus a biographical sketch — all fol¬ 
lowed at the bottom by a page number. They wanted all the fields to 
slide up to eliminate blank lines, except for the page number at the 
bottom of the page. But a normal layout set to slide objects up will 
move everything up, treating ALL blank lines as if they had been 
scissored out of the layout. 

The solution to this problem involved the use of a dummy “stop- 
slide” field. Figure 1 shows the no-slide layout. All the desired regular 
fields are positioned on the layout as required. The stop-slide field is 
A off on the far right side of the layout. The top of the stop-slide field is 

“ Stop-Slide" located near the top of the uppermost field on the layout; the bottom 

FiGld is located just above the top of the field that needs to be blocked from 
sliding up — in this case the page number field. 

Figure 2 shows the same layout in Browse mode for data entry. 
In the stop-slide field, single characters (numbers 1..9..) have been 
entered separated by Return characters and there are enough to fill 
up the field height. 


By 

S. C. Kim Hunter 
Acropolis Software 


Figure 1 
Un Slide Up 
Layout 
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.. -- You don't have to enter this Information manually for every rec- 

Un Slide Up ord—enter it once when all the other data has been entered, then use 

the Replace function to replicate it in all records. Or you can have 
(continued) FileMaker auto-enter the information for each new record. 

Figure 3 shows the Preview of the printed record. All the fields 
slide up except the page number field. Since the stop-slide field has 
nothing to do with the information being printed, it can be moved off 
to the right of the layout beyond the page margin line so it won’t show 
on the printed page, but will still weave its magic spell. 


Figure 2 
Un Slide Up 
Browse 


■□i 


FM+ NoSlideUp 




Records: 
7 


Sorted 


Name John Jones 

Address 1234 Main Street 
Suite 1234 


city/st/zip Denver, CO 99999 

Biography John Jones has been a 

FileMaker lover for over two 
years. He does all his business 
work with it. 


Stop-slide 
field with 
bottom above 
page * field 
top 


M 


2 

3 

4 

5 

6 

7 

8 
9 


m 


Figure 3 
Un Slide Up 
Preview 


FM+NoSlideUp 


Name John Jones 1 

Address 1234 Main Street 2 

Suite 1234 3 

ty/st/zip Denver, CO 99999 4 

Biography John Jones has been a 5 

FileMaker lover for over two s'™ 

years. He does all his business Stop-slide 7 

work with it. field with 8 

bottom above 9 

page * field 0 

top 1 

2 

3 

4 

5 

SI 

Hi 

1 

$ 

<5imn E> 



Preuiem: 


[Neat Page] 
(Page][B| 


□ Reduced 


[ Cancel) 
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Un Slide Up 

(continued) 


I’ve put the stop-slide field in view on the Figures so you can see 
how it works. You can see it, and you can see that it DOES work, but 
can you guess by what magic it works? 

I used to play “adventure” games for computers. They are fun, 
but I find FileMaker even more interesting. This might seem like I am 
criticizing FileMaker as being hard to use. But what I am saying is “If 
Michelangelo created a fantastic picture with MacPaint, would you 
criticize Apple for not telling you how to paint like Michelangelo?” 

As MacPaint gives you a blank page and some tools to draw with, 
FileMaker gives you another kind of blank page, different tools to 
build with and the ability to store data in the result. The designers 
have provided certain features with specific characteristics. If you are 
an explorer, you may well be able to find a unique use for those fea¬ 
tures that the creators never envisioned — such is the case of the 
stop-slide field. 

The concept of the Slide Up feature is that if you format fields on 
a layout to hold more than one line of data, then specify the layout to 
Slide Objects Up, empty lines in the fields will be eliminated from the 
layout just as if someone scissored them out. That is, if an Address 
field is formatted to show two lines on a layout, but in Browse mode, 
only one line is entered in a record, this record will be printed as if the 
second address line were “scissored” out of the layout: everything 
below will be moved up by the space removed when scissoring out the 
empty line. 

Sliding Up works by looking at the bottom of the field just above 
the field being printed. If the field above has blank lines, the blank 
lines are scissored out, and all the fields below are moved up. In 
Figure 1, the layout shows that all of the fields we want to slide up 
look up to each other; that is, the upper field bottoms are above the 
lower field tops. The bottom of the stop-slide field is not above any of 
them so they ignore it. 

Only the Page Number field looks up to the bottom of the stop- 
slide field. When it looks up, it sees that all of the lines in the stop- 
slide field are filled with dummy entries, so it doesn’t slide up. Just 
what we wanted. Voila! 

More neverending FileMaker magic! 

If you can’t figure out what I’m talking about, but need to know 
how to do this magic, give me a call during a weekday at 714-768- 
8490. 


Editor's Note: For more information on 
sliding and un-sliding, see Kim's article about 
Safe Sliding in Issue 4. 
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Weekend Date Calculations 


By 

Donald Clark 


When using FileMaker to calculate business dates, It Is some¬ 
times desirable to be able to eliminate the possibility of the result 
being a non-working day like Saturday or Sunday. In order to do so, 
you need to be able to determine the day of the week for any given 
date. It is then a simple matter to subtract one day If the calculation 
would otherwise result In a Saturday or to subtract two days if the 
result would otherwise be Sunday. Thus each weekend result Is con¬ 
verted to a Friday. (It is easy to adjust to some other day than Friday, 
If desired — a Monday, for example.) 

A reference date with a known day of the week needs to be deter¬ 
mined. One possibility is Friday, January 1, 1904, which is the first 
date that FileMaker will format. This date can also be represented by 
the date Integer 695056 (which can be determined by subtracting the 
number zero from the date 1/1/04 in a number field). 

Start by defining a date field, with a name such as CalcDate, that 
holds the computed date before any adjustments. A DaysSince field 
is then defined which Is the number of days since 1/1/04 represented 
by the CalcDate. It Is generated by subtracting the date integer 
695056 from CalcDate. 


What Day is It? 


The next step is to define the day-of-the-week (DOW) field. The 
week day Is computed using the FileMaker modulo (‘mod’) function, 
based on the reference date being Friday. In the DOW field, using a 
mod calculation, DaysSince is divided by seven with the remainder 
as the result. The remainder indicates the day of the week: all even 
multiples of seven give a result of zero (that Is, no remainder) which 
represents Friday. A result of 1 is then Saturday, 2 is Sunday, 3 is 
Monday, and so forth. 


Field Definition 


CalcDate 

Date 

<> 

DaysSince 

= CalcDate - 695056 


DOW 

- mod (DaysSince,?) 


CorrDate 

= if (DOW = 1,(CalcDate - l),if (DOW = 2,(C 



_ Field Definition _ 

Calculation Result is a O Number 

CorrDate = _ © Date _ 

if (DOW = 1,(CalcDate - 1),if (DOW = 2,(CalcDate - 2),CalcDate))| 

* 
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No Weekends 

(continued) 


To get the final corrected date (In the CorrDate field) the DOW Is 
tested and if it Is one or two, an appropriate correction is made. A 
nested if(„) function makes it easy. The fields involved are shown in 
the figures on the previous page. The figure on this page shows the 
calculated results for some example dates. 


r « File Edit Select Gadget* Format Foot Style 


CalcDate Test 




Records: 
6 


* 


CalcDate 

DaysSince 

DOW 

CorrDate 

5/5/88 

30806 

6 

05/05/88 

5/6/88 

30807 

0 

05/06/88 

5/7/88 

30808 

1 

05/06/88 

5/8/88 

30809 

2 

05/06/88 

5/9/88 

30810 

3 

05/09/88 

5/10/88 

3081 1 

4 

05/10/88 


Ki 


K> 


0 


Variations • The three calculation fields can be combined, if desired, into 

one equation by simple substitution. This eliminates the DaysSince 
and DOW fields. 

CorrDate = if((mod(CalcDate - 695056),?) = 1, 
(CalcDate - 1), if(mod(CalcDate - 695056),?) = 2, 
(CalcDate - 2), CalcDate) 

• Some may prefer not to have a weekday numbered with a zero. 
It is easy enough to simply add one in the DOW calculation so that 
Friday ends up a one, Saturday a two, Sunday a three, and so forth. 
The DOW calculation would then look like: 

DOUJ = mod(DaysSince,7)+1 

• Having calculated the week day, it will be nice for some applica¬ 
tions to display the alphabetic day. This is easy to do with FileMaker’s 
lookup capability. Since the week days are already defined in num¬ 
bers, the day number can become a key into a simple one-to-one 
translation lookup table that will retrieve the spelled weekday name. 
FileMaker can also format date fields to display the weekday. 
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Making Bar Graphs with FileMaker 


& Who said FileMaker can’t make graphs? Yes, yes — I know we are 
By not supposed to be able to make graphs, but nonetheless it is indeed 

Joe Kroeger possible. I got the idea from an old Helix example. It is really quite 

simple and it is FileMaker’s lookup capability combined with the pic¬ 
ture field capability that make it possible. 

There are many cases where graphs can be quite helpful. We 
have often heard that pictures can communicate information more 
effectively than words or numbers. You can use FileMaker to present 
a table of data derived from the information stored in the database. 
But sometimes it would be handy to be able to present some of the 
same data in a graph. 


There are three basic steps to making your own bar charts: (a) 
Three draw the bars, fb) build a lookup table, (c) design the file to display the 
Straightforward bar graph. 

Steps 

Draw the individual bars themselves using a draw or paint pro¬ 
gram. You need a ruler and/or a measuring tool of some kind to 
generate bars with some reasonable precision. Figure 1 shows a 
MacDraw screen with the measuring option enabled. You can design 
bars with whatever orientation, thickness, fill pattern and base length 
you need. 


A little planning is required to figure out the biggest bar that will 
fit in the allocated space of the picture field in the application file. The 
longest possible bar will usually need to be less than the size of a 
printed page. If the graph is to be viewed on a small Mac screen, it 

may even need to be a good 

Figure 1 bit smaller than a page. 


6 File Edit Style Font Layout Rrranye Fill Lines Pe 
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I suggest making a set of 
bars that represents percent¬ 
ages from 0 to 100. Once the 
length of the 100% bar is de¬ 
fined, it is easy to draw the 
remaining ones. 

To create a FileMaker 
lookup table of bars, only two 
fields are needed. One field 
holds the lookup key and the 
other is a picture field that 
holds the bars. Figures 2 and 
3 show the fields (using a list 
layout). Once the fields are 
defined, the key values are 
entered and then the bars are 
pasted in one-by-one. This is 
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Bar Graphs 

(continued) 


Figure 2 


Select 


where MultlFinder™ or Switcher™ come In very handy. Take care to 
associate the correct length of bar with the corresponding key value. 
When the lookup table Is sorted it will be obvious when a bar is out of 
place. (The easy solution in such a case is to change the key value, 
not the bar.) 

The Bars 50H lookup file actually has 51 entries — one is for a 
zero value. The 50 bars cover the range from 0 to 100%; thus there is 

a bar for every 2% value change. 
The ‘H’ in the file name indicates 
.. ..., .. ,. that the bars are horizontal. 



Records: 

51 


6<kI<)«H Formal Foal 


Length Bar 

0 

2 m 


To use this lookup file, con¬ 
struct a database that has the val¬ 
ues you are interested in plotting. 
Unfortunately, FileMaker Plus can¬ 
not use summary fields as lookup 
keys. The data to be graphed must 
come from data fields and calculated 
fields. 

Once you have the data of 
interest in non-summary fields 
(even if a few of the data points must 
be entered by hand), then each value 
must be converted into a percent of 
full scale. Let’s say you are plotting 
quarterly sales and you pick $10M 
as full scale on the horizontal axis of 
the graph. Then you want to set up 


r tfc File Edit Select Format Font Stylo 
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Length Bar 
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1 calculations to divide each quarter’s sales by 10M and multiply by 

ggf Graphs lOO. The calculated value is then used to perform a lookup from the 

Bars 50H file. The graph can be constructed within a single record or 
(continued) by putting one bar picture field in each record and then using the 

. “display-as-List” option. See Figure 4. 

The bars in the Bars 50H lookup table are about 0.15 inches high 
and the longest (100%) is roughly 4.75 inches long. Make each pic¬ 
ture field a little taller and longer than the biggest bar in the lookup 
file. Format the picture fields for “all that will fit” rather than scaled. 
Using Input Options, specify each picture field to be a lookup field, 
using the calculated % values as the lookup key. 

Naturally, there are all kinds of variations you can try. Bars can 
be unfilled or different shapes. A filled bar with no outline can be 
effective. Other kinds of graphic elements can be used instead of 
simple bars. A vertical orientation is a good alternative. 

If you are interested in working with bars like the ones I drew, I’ll 
send you a copy of the Bars 50H lookup table if you send $1 for 
shipping and handling plus a blank initialized diskette plus a self- 
addressed envelope big enough for a diskette. Send all three items to: 

Elk Horn Publishing 

PO Box 397 

Cupertino, CA 95015 

Who said FileMaker Plus can’t make graphs? 
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Addresses: Structures & Data 


One of the most frequent uses for any database is the storage of 
names and addresses. Sometimes the names and addresses exist for 
their own sake, sometimes as an integral part of a wider design goal. 
In a very large percentage of all database applications, no matter what 
ultimate end use is being served, part of the database system includes 
names and addresses. 

The names might be friends, family, subscribers, patients, 
clients, church members, mail order customers, passengers, alumni, 
user-group members, registered software owners, political party 
members, Macintosh users, limited partnership investors, prospects, 
constituents, patrons, buyers, shoppers, legislators, occupants, and 
on and on. This article will explore some of the ways to design the 
address portion of a database system and will touch on data entry and 
validation. 

There are many, many approaches to designing a name and 
address database. Where the needs of an application are modest, it is 
easy to put together a few simple fields. Where complicated ancillary 
functions depend on data that is tied to the names, it can be difficult 
to integrate all requirements without some serious design effort. 

If you are launching a new design, be sure to review the example 
designs included by Forethought or Nashoba with your FileMaker 
program. They can be a good starting point for some applications. 

A good first step is to consider what associated information needs 
to be stored in conjunction with the names, and how the name and 
address information is to be a) used, b) entered, and c) maintained. 

For large mail lists, the on-going effort required to keep it up to 
date can be significant. The US Postal Service maintains NCOA, the 
National Change Of Address database. They store just the address 
change cards submitted by people moving, yet that adds up to about 
1.5 million entries per month. Anyone putting together a mail list 
Figure 1 needs to develop good maintenance strategies. 

If nothing is needed beyond the raw name and address, 
the five fields shown for the FileMaker Report Turbine 
Works in Figure 1 may suffice. 

Note that one field is used for the full name. This makes 
it easy to format the entered name in order to take care of the 
many (nearly unending) variations of prefixes, suffixes, ini¬ 
tials, and so forth. Example: “Rev Jules R Brown III” goes in 
the same field as “Joe Smith" and as “Maj Joe Bob Smyth- 
Waring Jr”. “Dr. J. Smith” can be mixed with “J. Smith, MD” 
with relative ease. 


FUIR Turbine Works 


Name JULES R. BROWN 
Addr 123 MAIN STREET 
City O'HANK 
State AZ 
Zip 89898 


By 

Joe Kroeger 
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. Similarly, the single street address field accommodates various 

Addresses combinations of streets, numbers, suites, boxes, and so forth. For 

printing purposes, be sure to leave a multi-line address field on the 
(continued) layout to take care of the largest number of lines envisioned to be 

- — ■ M i entered. 


It may appear In Figure 1 that keystrokes are minimized since 
there are few fields to tab between. However, there are more spaces 
and returns to key in since there are fewer fields but more information 
Figure 2 111 each field. In general, one of the primary design goals for an 

address database that will hold a large number of records is the 
minimization of entry keystrokes. 


FfTTR Turbine UUorks 


First Name 

James 

Last Name 

Smith 

Addrl 


Addr2 

711 South North Street 

City 

South Covina 

State 

CA 

Zip 

90999 

Day Phone 

818-919-5050 


While something like Figure 1 is sufficient 
in some cases, it can be limiting in others. 
There is no opportunity, for example, to sort on 
the last name (although you can search on it), or 
to separate PO Box addresses from other types. 
There are also several missing pieces of infor¬ 
mation about the addressee that can often be of 
interest. 

Figure 2 goes a little farther. Note that 
there are separate first and last name fields, the 
address has been split into two fields, and there 
is now a field for a telephone number. You must 
make up your own rules about using a middle 
initial in the First Name field (I usually omit all 
middle initials) and about how the address is 
split between the two fields. 


Figure 3 

FfTIR Turbine UUorks 


Prefix 

MR 

First Name 

JAMES 

Last Name 

BROWN 

Title 

PRESIDENT 

Organization 

BROWN at LEE 

PO/MS/Apt/Suite 

SUITE A7 

Street 

123 NORTH MAIN STREET 

City 

HANK 

State 

AZ 

Zip 

89888 

Day Phone 

800-555-1234 


Figure 3 goes a lot farther. It in¬ 
cludes a field for personal title (Prefix), 
business title, and organization. The 
prefix field really comes in handy for a 
whole range of situations. Mr., Mrs., 
Miss and Ms go there of course, when 
they are required (in most cases they 
can be omitted). But Prefix really 
comes into its own for items like Rev, 
Fr, Sr, Dr, Maj, LCmdr, etc. 

The address fields in Figure 3 have 
been dedicated — the second one to 
the street address and the first one to 
everything else: PO Box, Mail Stop, 
Apartment, Suite, Department, Floor, 
Room, and all those other necessary 
address adjuncts. 

Going beyond Figure 3 we can add 
fields to manage the database and 
keep track of relationships with the 
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Addresses 

(continued) 

Figure 4 


addressee. Figure 4 shows an example layout. The Name Code field 
provides information for lookup purposes and for dup-hunting. It is 
simply a combination of the first three digits of the last name plus the 
first five digits of the zip code. Since a name code so constructed is not 
necessarily unique, there is a Dup OK field which indicates that a 
different person in the database has the same Name Code. An ac¬ 
count number or customer number could be used instead of a name 
code. 



Organization 

PO/MS/Apt/Ste 

Street 

City 

State 



Day Phone |.P.aU .P.ftpnfc 


Name Entry Date 
Last Contact Date 
Last Contact Code 


Name. Entry. J)att 
U 3 tC 0 .ntac.tPat 
LaatJ 


[twnill temp 
IStatd Status 
T.yPfil Type 


Figure 5 


ss s . . gags 

flddr Style 


Name Code KR095015 

Dup OK 


FMR Turbine Works 


Prefix First Name Last Name 

MR JOE KROEGER 

Title OWNER 

Organization ELK HORN PUBLISHING 
PO/MS/Apt/Ste P0 BOX 397 
Street 

City CUPERTINO 

State CA Zip 95015 Country 

Day Phone 408—946—1767 

Name Entry Date 5/12/86 
Last Contact Date 2/2/88 
Last Contact Code M 


a temp 
2S Status 
Type 
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Addresses 

(continued) 


I usually position the Name Code field in the top left area of the 
layout. That way it automatically contains the cursor when Find is 
selected, making View Index and Paste easier. 

Numerous types of additional information are possible about the 
addressee. Things like Name Entry Date, Last Order Date, Type of 
Member, Active/Inactive Status are all easy to implement. Some ex¬ 
amples are shown in Figure 4. Figure 5 shows the browse screen of 
the Figure 4 layout. This design is quite versatile and I use variations 
of it in several types of applications. 

A few suggestions for addressing data: 

• Make all characters upper case. This is easier to print clearly 
and easier for the Post Office to read. Some applications, however, 
like addressing invoices, may want to have better-looking upper/ 
lower case. 


• Do not use periods in abbreviations. 

• Common words used in addresses usually have accepted ab¬ 
breviations: ST, STE, PO BOX, AVE, RD, LN, CIR, etc. 

• Always use the two-character abbreviation for states. Thus: CA 
instead of California or Cal. Here are the standard state abbreviations 
within the United States: 


AL 

Alabama 

KY 

Kentucky 

ND 

North Dakota 

AK 

Alaska 

LA 

Louisiana 

OH 

Ohio 

AZ 

Arizona 

ME 

Maine 

OK 

Oklahoma 

AS 

Arkansas 

MD 

Maryland 

OR 

Oregon 

CA 

California 

MA 

Massachusetts 

PA 

Pennsylvania 

CO 

Colorado 

MI 

Michigan 

RI 

Rhode Island 

CT 

Connecticut 

MN 

Minnesota 

SC 

South Carolina 

DC 

District of Columbia 

MS 

Mississippi 

SD 

South Dakota 

DE 

Delaware 

MO 

Missouri 

TN 

Tennessee 

FL 

Florida 

MT 

Montana 

TX 

Texas 

GA 

Georgia 

NB 

Nebraska 

UT 

Utah 

HI 

Hawaii 

NV 

Nevada 

VT 

Vermont 

ID 

Idaho 

NH 

New Hampshire 

VA 

Virginia 

IL 

Illinois 

NJ 

New Jersey 

WA 

Washington 

IN 

Indiana 

NM 

New Mexico 

WV 

West Virginia 

IA 

Iowa 

NY 

New York 

WI 

Wisconsin 

KS 

Kansas 

NC 

North Carolina 

WY 

Wyoming 


• Even if you have a case where you need to use the full names of 
the states, enter the two-character abbreviations anyway, in order to 
save keystrokes. Then use a lookup table to find the full spelling from 
the abbreviation. 
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- —.— • Lookups can often be used to eliminate redundant data entry. 

Addresses For example, some designers construct a large file that are used to 

look up the city and state based on the entered zip code. This elimi- 
(continued) nates the entry of city and state information with every record. Not 

- only does this save keystrokes, it also helps minimize entry errors: if 

the lookup file is correct, then the entered record will be correct as 
well. Unless, that is, the zip is entered incorrectly by the operator. 
But the operator entering the new record has an opportunity to check 
visually the city and state presented by the lookup file. It does mean 
that having the lookup information correct is critical. 


Given the number of zip codes in the US, the task of assembling 
a zip lookup is daunting. But FileMaker helps by allowing lookup 
tables to be constructed using a range of key values instead of having 
to enter each individual one. Thus only the zips that deliniate breaks 
between cities need be entered. One way to get a start on creating 
such a table is to extract the city, state and zip information from 
existing address files. 


Figure 6 



Gaz 00-09 Gaz10-19 Gaz20-39 Gaz40-59 



Gaz 60-79 Gaz 80-89 Gaz 90-99 


* 


• For very large databases of addresses, it 
is sometimes worthwhile to split the records 
into multiple files. At the Diskette Gazette 
there are more than 150,000 addresses — 
unwieldy in one file. The Gazette addresses 
are split by zip code groups into seven differ¬ 
ent files (see Figure 6). When the original split 
was made there were five files evenly divided 
across the 00000 to 99999 zip code spectrum. 
But the country is weighted heavily at the 
East and West coasts, so each end was later 
split into two files. 


With multiple address files, searches and sorts are faster. More 
than one person can work on addresses at the same time. But when 
someone in the database changes address, their record sometimes 
has to be moved from one file to another. 


• Sometimes when looking for dups from among a large number 
of candidates, a different layout like Figure 7 is helpful. Figure 4 
shows one record at a time while Figure 7 shows several records. 
Something like Figure 7 works better on a wider screen than the 
standard small-screen Macs. Figure 8 shows the Browse version of 
Figure 7. By sorting on the Name Code first, a quick inspection of the 
screen will often reveal true dups and one of them can be marked for 
later deletion or can be deleted on the spot. 


Figure 7 


Header] Order Pale FName LName 

Organization PO/MS/Apt/Suite J 




Status |StdO Dup l.P.ud temp i tend 

Body"! -" 
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Addresses 

(continued) 


Figure 8 


After putting all that work into creating a nifty database, we then 
run into the real world of (gasp!) INVALID DATA. Data errors can be 
created in a variety of ways. When there are several users of a data¬ 
base, there may be misunderstandings, typing errors, redundant 
entries. Imported data may be wrong. Changes in the design may not 
allow for all types of data. The information provided by addressees is 
sometimes incorrect. 


File Edit Select (><ukj«U Formal Font Style 


FMR Demo 


Code 


Order Date FName LName 


Organization PO/MS/Apt/Suite 


KR095555 ii 08/22/87 ijWALT 


KROGER 


Status |C (| Dupj j temp 


IjK ASSOC 


*123 


KRoJl 777 JUDITH 

Statusp | Dup[ | 

KR0ENEN 
tempi ] 

DELI REST 

KR093100 

10/06/87 HERB 

SMITH 


Status |C 1 Dup[ j 

tempi b 1 


KR09811 1 

MARC 

KR0N 

ALSO INC 

Status )S 1 Dup| | 

tempi | 


KR095000 

HENRY 

RAINE 

ELK HORN 

Status|E | Dup| | 

tempi " j 


KR095015 

03/18/88 JOE 

KR0EGER 

ELK HORN 




IS 

a 


llliilil 
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Some errors are 
obvious ones, like a 
misspelled name or 
mis-entry of a code like 
a social security num¬ 
ber or a name code. 
But some are more 
subtle and may not 
show up until an at¬ 
tempt is made to find 
some values. File¬ 
Maker's View Index 
capability is a big help 
in many cases. 

Fortunately, there 
is a lot of redundancy 
inherent in typical 
name and address da¬ 
tabases. This means 
there are validation 
cross-checks that help 
clean-up your data. 


Among the many things you can look for: 


• Proper state abbreviations. 


• State and zip code correlation. 


• Correct zip code formats. 

• Code combinations —example: a status field that indicates the 
name is a customer should not have an empty Last Order Date field. 


• Duplicate name codes. 

• Wrong name code characters — you need a name code rule for 
cases like O’Brien since FileMaker does not like ' and other punction 
marks. 


• Duplicate telephone numbers — can help find mixed home/ 
work addresses for an individual. 

In addition, be sure to take advantage of the capabilities of File¬ 
Maker to aid data entry: unique values, structured fields, lookups, 
auto-entry, and so forth, all help to prevent errors. 
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Addresses 

(continued) 


Figure 8 


After putting all that work Into creating a nifty database, we then 
run Into the real world of (gasp!) INVALID DATA. Data errors can be 
created In a variety of ways. When there are several users of a data¬ 
base, there may be misunderstandings, typing errors, redundant 
entries. Imported data may be wrong. Changes In the design may not 
allow for all types of data. The Information provided by addressees is 
sometimes Incorrect. 
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Some errors are 
obvious ones, like a 
misspelled name or 
mis-entry of a code like 
a social security num¬ 
ber or a name code. 
But some are more 
subtle and may not 
show up until an at¬ 
tempt is made to And 
some values. File¬ 
Maker's View Index 
capability is a big help 
in many cases. 

Fortunately, there 
is a lot of redundancy 
inherent in typical 
name and address da¬ 
tabases. This means 
there are validation 
cross-checks that help 
clean-up your data. 


Among the many things you can look for: 


• Proper state abbreviations. 


• State and zip code correlation. 


• Correct zip code formats. 

• Code combinations —example: a status field that indicates the 
name is a customer should not have an empty Last Order Date field. 


• Duplicate name codes. 

• Wrong name code characters — you need a name code rule for 
cases like O’Brien since FileMaker does not like ' and other punction 
marks. 


• Duplicate telephone numbers — can help find mixed home/ 
work addresses for an individual. 

In addition, be sure to take advantage of the capabilities of File¬ 
Maker to aid data entry: unique values, structured fields, lookups, 
auto-entry, and so forth, all help to prevent errors. 
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Consulting Resources 


• Consulting 

• Designing 

• Training 


■0* Additional expertise can prove to be productive with some pro¬ 
jects and in some contexts. Consultants can help design databases 
from scratch, debug existing implementations, provide one-on-one 
instruction and larger training classes. The names listed here are 
potential sources of help when a consultant is needed. They are all 
subscribers but they have not been qualified by the newsletter and 
normal caution should be exercised. Please write if you would like to 
be included on this list or if you have experience with a consultant you 
can recommend. 


S, C, Kim Hunter 
Acropolis Software 
24781 Acropolis 
Mission Viejo, CA 92691 
714-250-6280 

John Winson 
Frontline Marketing 
PO Box 327 
Beverly, MA 01915 
617-927-2535 

Steve Proehl 
916 Rodney Drive 
San Leandro, CA 94577 
415-483-3683 

Jonathan Posner 
44 Greenwich Avenue 
New York, NY 10011 
212-243-0038 

Mike Singleton 
Professional Design Support 
2315 29th Street 
San Diego, CA 92104 
619-284-5620 


David Lagerson 
8412 McNulty Avenue 
Canoga Park, CA 91306 
818-352-8711 

Tom Price 
Price & Associates 
PO Box 153 
Peabody, MA 01960 
617-532-0762 

David Dent 
Software Solutions 
1190 Gravenstein Hwy S 
Sebastopol, CA 95472 
707-829-5377 

John Foster 
Adjuvant Instruments 
2834 Johnson Avenue 
Alameda, CA 94501 

Jim Schwertman 
Mac Solutions 
1168 Willow Glen Way 
San Jose, CA 95125 
408-298-4333 


Janet Tokerud 
#1 

322 30th Avenue 

San Francisco, CA 94121 

415-751-9330 

Michael Degnan 
Suite 6 

1447 University Avenue 
Berkeley, CA 94702 
415-644-2381 

Jeff Nathanson 
PO Box 587 
Old Orchard Beach 
ME 04064 
207-934-7509 

Joe Kroeger 
Elk Horn Publishing 
PO Box 397 
Cupertino, CA 95015 
408-946-1767 
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Addresses 

(continued) 


I usually position the Name Code field in the top left area of the 
layout. That way it automatically contains the cursor when Find is 
selected, making View Index and Paste easier. 

Numerous types of additional information are possible about the 
addressee. Things like Name Entry Date, Last Order Date, Type of 
Member, Active/Inactive Status are all easy to implement. Some ex¬ 
amples are shown in Figure 4. Figure 5 shows the browse screen of 
the Figure 4 layout. This design is quite versatile and I use variations 
of it in several types of applications. 

A few suggestions for addressing data: 

• Make all characters upper case. This is easier to print clearly 
and easier for the Post Office to read. Some applications, however, 
like addressing invoices, may want to have better-looking upper/ 
lower case. 


• Do not use periods in abbreviations. 

• Common words used in addresses usually have accepted ab¬ 
breviations: ST, STE, PO BOX, AVE, RD, LN, CIR, etc. 

• Always use the two-character abbreviation for states. Thus: CA 
instead of California or Cal. Here are the standard state abbreviations 
within the United States: 


AL 

Alabama 

KY 

Kentucky 

ND 

North Dakota 

AK 

Alaska 

LA 

Louisiana 

OH 

Ohio 

AZ 

Arizona 

ME 

Maine 

OK 

Oklahoma 

AS 

Arkansas 

MD 

Maryland 

OR 

Oregon 

CA 

California 

MA 

Massachusetts 

PA 

Pennsylvania 

CO 

Colorado 

MI 

Michigan 

RI 

Rhode Island 

CT 

Connecticut 

MN 

Minnesota 

SC 

South Carolina 

DC 

District of Columbia 

MS 

Mississippi 

SD 

South Dakota 

DE 

Delaware 

MO 

Missouri 

TN 

Tennessee 

FL 

Florida 

MT 

Montana 

TX 

Texas 

GA 

Georgia 

NB 

Nebraska 

UT 

Utah 

HI 

Hawaii 

NV 

Nevada 

VT 

Vermont 

ID 

Idaho 

NH 

New Hampshire 

VA 

Virginia 

IL 

Illinois 

NJ 

New Jersey 

WA 

Washington 

IN 

Indiana 

NM 

New Mexico 

WV 

West Virginia 

IA 

Iowa 

NY 

New York 

WI 

Wisconsin 

KS 

Kansas 

NC 

North Carolina 

WY 

Wyoming 


• Even if you have a case where you need to use the full names of 
the states, enter the two-character abbreviations anyway, in order to 
save keystrokes. Then use a lookup table to find the full spelling from 
the abbreviation. 
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You don't have to enter this Information manually for every rec¬ 
ord — enter it once when all the other data has been entered, then use 
the Replace function to replicate it in all records. Or you can have 
FileMaker auto-enter the information for each new record. 

Figure 3 shows the Preview of the printed record. All the fields 
slide up except the page number field. Since the stop-slide field has 
nothing to do with the information being printed, it can be moved off 
to the right of the layout beyond the page margin line so it won’t show 
on the printed page, but will still weave its magic spell. 


Figure 2 
Un Slide Up 
Browse 


Figure 3 
Un Slide Up 
Preview 




Un Slide Up 

(continued) 
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-- Similarly, the single street address field accommodates various 

Addre$Se$ combinations of streets, numbers, suites, boxes, and so forth. For 

printing purposes, be sure to leave a multi-line address field on the 
(continued) layout to take care of the largest number of lines envisioned to be 

■ entered. 


It may appear in Figure 1 that keystrokes are minimized since 
there are few fields to tab between. However, there are more spaces 
and returns to key In since there are fewer fields but more information 
Figure 2 111 each field. In general, one of the primary design goals for an 

address database that will hold a large number of records is the 
minimization of entry keystrokes. 


FITIR Turbine UUorks 


First Name 

James 

Last Name 

Smith 

Addrl 


Addr2 

711 South North Street 

City 

South Covina 

State 

CA 

Zip 

90999 

Day Phone 

818-919-5050 


While something like Figure 1 is sufficient 
in some cases, it can be limiting In others. 
There is no opportunity, for example, to sort on 
the last name (although you can search on it), or 
to separate PO Box addresses from other types. 
There are also several missing pieces of infor¬ 
mation about the addressee that can often be of 
interest. 

Figure 2 goes a little farther. Note that 
there are separate first and last name fields, the 
address has been split into two fields, and there 
is now a field for a telephone number. You must 
make up your own rules about using a middle 
initial In the First Name field (I usually omit all 
middle initials) and about how the address is 
split between the two fields. 


Figure 3 

FfTIR Turbine UUorks 


Prefix 

MR 

First Name 

JAMES 

Last Name 

BROVN 

Title 

PRESIDENT 

Organization 

BROVN & LEE 

PO/MS/Apt/Suite 

SUITE A7 

Street 

123 NORTH MAIN STREET 

City 

HANK 

State 

AZ 

Zip 

89888 

Day Phone 

800-555-1234 


Figure 3 goes a lot farther. It in¬ 
cludes a field for personal title (Prefix), 
business title, and organization. The 
prefix field really comes in handy for a 
whole range of situations. Mr., Mrs., 
Miss and Ms go there of course, when 
they are required (in most cases they 
can be omitted). But Prefix really 
comes into its own for items like Rev, 
Fr, Sr, Dr, Maj, LCmdr, etc. 

The address fields in Figure 3 have 
been dedicated — the second one to 
the street address and the first one to 
everything else: PO Box, Mail Stop, 
Apartment, Suite, Department, Floor, 
Room, and all those other necessary 
address adjuncts. 

Going beyond Figure 3 we can add 
fields to manage the database and 
keep track of relationships with the 
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Weekend Date Calculations 


By 

Donald Clark 


When using FileMaker to calculate business dates, it is some¬ 
times desirable to be able to eliminate the possibility of the result 
being a non-working day like Saturday or Sunday. In order to do so, 
you need to be able to determine the day of the week for any given 
date. It is then a simple matter to subtract one day If the calculation 
would otherwise result In a Saturday or to subtract two days If the 
result would otherwise be Sunday. Thus each weekend result is con¬ 
verted to a Friday. (It is easy to adjust to some other day than Friday, 
If desired — a Monday, for example.) 

A reference date with a known day of the week needs to be deter¬ 
mined. One possibility is Friday, January 1, 1904, which is the first 
date that FileMaker will format. This date can also be represented by 
the date Integer 695056 (which can be determined by subtracting the 
number zero from the date 1/1/04 In a number field). 

Start by defining a date field, with a name such as CalcDate, that 
holds the computed date before any adjustments. A DaysSince field 
is then defined which is the number of days since 1/1/04 represented 
by the CalcDate. It is generated by subtracting the date integer 
695056 from CalcDate. 


What Day is It? 


The next step is to define the day-of-the-week (DOW) field. The 
week day Is computed using the FileMaker modulo (‘mod’) function, 
based on the reference date being Friday. In the DOW field, using a 
mod calculation, DaysSince is divided by seven with the remainder 
as the result. The remainder indicates the day of the week: all even 
multiples of seven give a result of zero (that is, no remainder) which 
represents Friday. A result of 1 is then Saturday, 2 is Sunday, 3 is 
Monday, and so forth. 


Field Definition 


CalcDate 

Date 

<> 

DaysSince 

= CalcDate - 695056 


DOUJ 

= mod (DaysSince,7) 


CorrDate 

= if (DOUJ = 1 .(CalcDate - 1),if (DOUJ = 2,(C 



_ Field Definition _ 

Calculation Result is a O Number 

CorrDate = _ © Date _ 

if (DOUJ = 1,(CalcDate - 1),if (DOID = 2,(CalcDate - 2),CalcDate))| 

* 
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calculations to divide each quarter’s sales by 10M and multiply by 
100. The calculated value Is then used to perform a lookup from the 
Bars SOH file. The graph can be constructed within a single record or 
by putting one bar picture field in each record and then using the 
“display-as-List” option. See Figure 4. 

The bars in the Bars SOH lookup table are about 0.15 inches high 
and the longest (100%) is roughly 4.75 inches long. Make each pic¬ 
ture field a little taller and longer than the biggest bar in the lookup 
file. Format the picture fields for “all that will fit" rather than scaled. 
Using Input Options, specify each picture field to be a lookup field, 
using the calculated % values as the lookup key. 

Naturally, there are all kinds of variations you can try. Bars can 
be unfilled or different shapes. A filled bar with no outline can be 
effective. Other kinds of graphic elements can be used instead of 
simple bars. A vertical orientation is a good alternative. 

If you are interested in working with bars like the ones I drew, I’ll 
send you a copy of the Bars SOH lookup table if you send $1 for 
shipping and handling plus a blank initialized diskette plus a self- 
addressed envelope big enough for a diskette. Send all three items to: 

Elk Horn Publishing 

PO Box 397 

Cupertino, CA 95015 

Who said FileMaker Plus can’t make graphs? 


r 6 File Edit Select Gadget* Format Font Stylo 



Bar Graphs 

(continued) 
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Making Bar Graphs with FileMaker 


^ Who said FileMaker can’t make graphs? Yes, yes — I know we are 
By not supposed to be able to make graphs, but nonetheless it is indeed 

Joe Kroeger possible. I got the idea from an old Helix example. It is really quite 

simple and it is FileMaker’s lookup capability combined with the pic¬ 
ture field capability that make it possible. 

There are many cases where graphs can be quite helpful. We 
have often heard that pictures can communicate information more 
effectively than words or numbers. You can use FileMaker to present 
a table of data derived from the information stored in the database. 
But sometimes it would be handy to be able to present some of the 
same data in a graph. 


There are three basic steps to making your own bar charts: (a) 
Three draw the bars, (b) build a lookup table, (c) design the file to display the 
Straightforward bar graph . 

Steps 

Draw the individual bars themselves using a draw or paint pro¬ 
gram. You need a ruler and/or a measuring tool of some kind to 
generate bars with some reasonable precision. Figure 1 shows a 
MacDraw screen with the measuring option enabled. You can design 
bars with whatever orientation, thickness, fill pattern and base length 
you need. 


A little planning Is required to figure out the biggest bar that will 
fit in the allocated space of the picture field in the application file. The 
longest possible bar will usually need to be less than the size of a 
printed page. If the graph is to be viewed on a small Mac screen, it 

may even need to be a good 

Figure 1 bit smaller than a page. 


6 File Edit Style Font Layout Arrange Fill Lines Pe 



I suggest making a set of 
bars that represents percent¬ 
ages from 0 to 100. Once the 
length of the 100% bar is de¬ 
fined, it is easy to draw the 
remaining ones. 

To create a FileMaker 
lookup table of bars, only two 
fields are needed. One field 
holds the lookup key and the 
other is a picture field that 
holds the bars. Figures 2 and 
3 show the fields (using a list 
layout). Once the fields are 
defined, the key values are 
entered and then the bars are 
pasted in one-by-one. This is 
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